home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr18 / pgp23.zip / PGPDOC1.DOC < prev    next >
Text File  |  1993-06-15  |  89KB  |  1,800 lines

  1.  
  2.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 1
  3.  
  4.  
  5.                           Phil's Pretty Good Software
  6.                                     Presents
  7.       
  8.                                       ===
  9.                                       PGP
  10.                                       ===
  11.       
  12.                               Pretty Good Privacy
  13.                       Public Key Encryption for the Masses
  14.       
  15.       
  16.                            --------------------------
  17.                                 PGP User's Guide
  18.                            Volume I: Essential Topics
  19.                            --------------------------
  20.                               by Philip Zimmermann
  21.                                Revised 14 Jun 93
  22.       
  23.       
  24.                           PGP Version 2.3 - 13 Jun 93
  25.                                   Software by
  26.                                Philip Zimmermann
  27.                                       with
  28.                 Branko Lankester, Hal Finney, and Peter Gutmann
  29.       
  30.       
  31.       
  32.       
  33.      Synopsis:  PGP uses public-key encryption to protect E-mail and data
  34.      files.  Communicate securely with people you've never met, with no
  35.      secure channels needed for prior exchange of keys.  PGP is well
  36.      featured and fast, with sophisticated key management, digital
  37.      signatures, data compression, and good ergonomic design.
  38.       
  39.       
  40.      Software and documentation (c) Copyright 1990-1992 Philip Zimmermann. 
  41.      For information on PGP licensing, distribution, copyrights, patents,
  42.      trademarks, liability limitations, and export controls, see the
  43.      "Legal Issues" section in the "PGP User's Guide, Volume II: Special
  44.      Topics".
  45.       
  46.       
  47.  
  48.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 2
  49.  
  50.  
  51.       
  52.      Contents
  53.      ========
  54.       
  55.      Quick Overview
  56.      Why Do You Need PGP?
  57.      How it Works
  58.      Installing PGP
  59.      How to Use PGP
  60.        To See a Usage Summary
  61.        Encrypting a Message
  62.        Encrypting a Message to Multiple Recipients
  63.        Signing a Message
  64.        Signing and then Encrypting
  65.        Using Just Conventional Encryption
  66.        Decrypting and Checking Signatures
  67.        Managing Keys
  68.          RSA Key Generation
  69.          Adding a Key to Your Key Ring
  70.          Removing a Key or User ID from Your Key Ring
  71.          Extracting (copying) a Key from Your Key Ring
  72.          Viewing the Contents of Your Key Ring
  73.          How to Protect Public Keys from Tampering
  74.          How Does PGP Keep Track of Which Keys are Valid?
  75.          How to Protect Secret Keys from Disclosure
  76.          Revoking a Public Key
  77.          What If You Lose Your Secret Key?
  78.      Advanced Topics
  79.        Sending Ciphertext Through E-mail Channels: Radix-64 Format
  80.        Environmental Variable for Path Name
  81.        Setting Configuration Parameters: CONFIG.TXT
  82.      Vulnerabilities
  83.      Beware of Snake Oil
  84.      PGP Quick Reference
  85.      Legal Issues
  86.      Acknowledgments
  87.      About the Author
  88.       
  89.       
  90.  
  91.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 3
  92.  
  93.  
  94.       
  95.      Quick Overview
  96.      =============
  97.       
  98.      Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
  99.      high security cryptographic software application for MSDOS, Unix,
  100.      VAX/VMS, and other computers.  PGP allows people to exchange files or
  101.      messages with privacy, authentication, and convenience.  Privacy
  102.      means that only those intended to receive a message can read it. 
  103.      Authentication means that messages that appear to be from a
  104.      particular person can only have originated from that person. 
  105.      Convenience means that privacy and authentication are provided
  106.      without the hassles of managing keys associated with conventional
  107.      cryptographic software.  No secure channels are needed to exchange
  108.      keys between users, which makes PGP much easier to use.  This is
  109.      because PGP is based on a powerful new technology called "public key"
  110.      cryptography.  
  111.       
  112.      PGP combines the convenience of the Rivest-Shamir-Adleman (RSA)
  113.      public key cryptosystem with the speed of conventional cryptography,
  114.      message digests for digital signatures, data compression before
  115.      encryption, good ergonomic design, and sophisticated key management. 
  116.      And PGP performs the public-key functions faster than most other
  117.      software implementations.  PGP is public key cryptography for the
  118.      masses.
  119.       
  120.      PGP does not provide any built-in modem communications capability. 
  121.      You must use a separate software product for that.
  122.       
  123.      This document, "Volume I: Essential Topics", only explains the
  124.      essential concepts for using PGP, and should be read by all PGP
  125.      users.  "Volume II: Special Topics" covers the advanced features of
  126.      PGP and other special topics, and may be read by more serious PGP
  127.      users.  Neither volume explains the underlying technology details of
  128.      cryptographic algorithms and data structures.  
  129.       
  130.       
  131.  
  132.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 4
  133.  
  134.  
  135.       
  136.      Why Do You Need PGP?
  137.      ====================
  138.       
  139.      It's personal.  It's private.  And it's no one's business but yours.
  140.      You may be planning a political campaign, discussing your taxes, or
  141.      having an illicit affair.  Or you may be doing something that you
  142.      feel shouldn't be illegal, but is.  Whatever it is, you don't want
  143.      your private electronic mail (E-mail) or confidential documents read
  144.      by anyone else.  There's nothing wrong with asserting your privacy. 
  145.      Privacy is as apple-pie as the Constitution.  
  146.       
  147.      Perhaps you think your E-mail is legitimate enough that encryption is
  148.      unwarranted.  If you really are a law-abiding citizen with nothing to
  149.      hide, then why don't you always send your paper mail on postcards? 
  150.      Why not submit to drug testing on demand?  Why require a warrant for
  151.      police searches of your house?  Are you trying to hide something? 
  152.      You must be a subversive or a drug dealer if you hide your mail
  153.      inside envelopes.  Or maybe a paranoid nut.  Do law-abiding citizens
  154.      have any need to encrypt their E-mail?
  155.       
  156.      What if everyone believed that law-abiding citizens should use
  157.      postcards for their mail?  If some brave soul tried to assert his
  158.      privacy by using an envelope for his mail, it would draw suspicion. 
  159.      Perhaps the authorities would open his mail to see what he's hiding. 
  160.      Fortunately, we don't live in that kind of world, because everyone
  161.      protects most of their mail with envelopes.  So no one draws suspicion
  162.      by asserting their privacy with an envelope.  There's safety in
  163.      numbers.  Analogously, it would be nice if everyone routinely used
  164.      encryption for all their E-mail, innocent or not, so that no one drew
  165.      suspicion by asserting their E-mail privacy with encryption.  Think
  166.      of it as a form of solidarity.
  167.       
  168.      Today, if the Government wants to violate the privacy of ordinary
  169.      citizens, it has to expend a certain amount of expense and labor to
  170.      intercept and steam open and read paper mail, and listen to and
  171.      possibly transcribe spoken telephone conversation.  This kind of
  172.      labor-intensive monitoring is not practical on a large scale.  This
  173.      is only done in important cases when it seems worthwhile. 
  174.       
  175.      More and more of our private communications are being routed through
  176.      electronic channels.  Electronic mail is gradually replacing
  177.      conventional paper mail.  E-mail messages are just too easy to
  178.      intercept and scan for interesting keywords.  This can be done
  179.      easily, routinely, automatically, and undetectably on a grand scale. 
  180.      International cablegrams are already scanned this way on a large
  181.      scale by the NSA. 
  182.       
  183.      We are moving toward a future when the nation will be crisscrossed
  184.      with high capacity fiber optic data networks linking together all our
  185.      increasingly ubiquitous personal computers.  E-mail will be the norm
  186.      for everyone, not the novelty it is today.  The Government will
  187.      protect our E-mail with Government-designed encryption protocols. 
  188.      Probably most people will trust that.  But perhaps some people will
  189.      prefer their own protective measures.
  190.       
  191.  
  192.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 5
  193.  
  194.  
  195.      Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling
  196.      measure buried in it.  If this non-binding resolution had become real
  197.      law, it would have forced manufacturers of secure communications
  198.      equipment to insert special "trap doors" in their products, so that
  199.      the Government can read anyone's encrypted messages.  It reads:  "It
  200.      is the sense of Congress that providers of electronic communications
  201.      services and manufacturers of electronic communications service
  202.      equipment shall insure that communications systems permit the
  203.      Government to obtain the plain text contents of voice, data, and
  204.      other communications when appropriately authorized by law."  This
  205.      measure was defeated after rigorous protest from civil libertarians
  206.      and industry groups.  
  207.       
  208.      In 1992, the FBI Digital Telephony wiretap proposal was introduced to
  209.      Congress.  It would require all manufacturers of communications
  210.      equipment to build in special remote wiretap ports that would enable
  211.      the FBI to remotely wiretap all forms of electronic communication
  212.      from FBI offices.  Although it never attracted any sponsors in
  213.      Congress because of citizen opposition, it will be reintroduced in
  214.      1993.  
  215.       
  216.      Most alarming of all is the White House's bold new encryption policy
  217.      initiative, under development at NSA for four years, and unveiled
  218.      April 16th, 1993.  The centerpiece of this initiative is a
  219.      Government-built encryption device, called the "Clipper" chip,
  220.      containing a new classified NSA encryption algorithm.  The Government
  221.      is encouraging private industry to design it into all their secure
  222.      communication products, like secure phones, secure FAX, etc.  AT&T is
  223.      now putting the Clipper into all their secure voice products.  The
  224.      catch:  At the time of manufacture, each Clipper chip will be loaded
  225.      with its own unique key, and the Government gets to keep a copy,
  226.      placed in escrow.  Not to worry, though-- the Government promises
  227.      that they will use these keys to read your traffic only when duly
  228.      authorized by law.  Of course, to make Clipper completely effective,
  229.      the next logical step would be to outlaw other forms of cryptography.
  230.       
  231.      If privacy is outlawed, only outlaws will have privacy.  Intelligence
  232.      agencies have access to good cryptographic technology.  So do the big
  233.      arms and drug traffickers.  So do defense contractors, oil companies,
  234.      and other corporate giants.  But ordinary people and grassroots
  235.      political organizations mostly have not had access to affordable
  236.      "military grade" public-key cryptographic technology.  Until now.
  237.       
  238.      PGP empowers people to take their privacy into their own hands.  
  239.      There's a growing social need for it.  That's why I wrote it.
  240.       
  241.       
  242.  
  243.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 6
  244.  
  245.  
  246.       
  247.      How it Works
  248.      ============
  249.       
  250.      It would help if you were already familiar with the concept of
  251.      cryptography in general and public key cryptography in particular. 
  252.      Nonetheless, here are a few introductory remarks about public key
  253.      cryptography.
  254.       
  255.      First, some elementary terminology.  Suppose I want to send you a
  256.      message, but I don't want anyone but you to be able to read it.  I
  257.      can "encrypt", or "encipher" the message, which means I scramble it
  258.      up in a hopelessly complicated way, rendering it unreadable to anyone
  259.      except you, the intended recipient of the message.  I supply a
  260.      cryptographic "key" to encrypt the message, and you have to use the
  261.      same key to decipher or "decrypt" it.  At least that's how it works
  262.      in conventional "single-key" cryptosystems.
  263.       
  264.      In conventional cryptosystems, such as the US Federal Data Encryption
  265.      Standard (DES), a single key is used for both encryption and
  266.      decryption.  This means that a key must be initially transmitted via
  267.      secure channels so that both parties can know it before encrypted
  268.      messages can be sent over insecure channels.  This may be
  269.      inconvenient.  If you have a secure channel for exchanging keys, then
  270.      why do you need cryptography in the first place?
  271.       
  272.      In public key cryptosystems, everyone has two related complementary
  273.      keys, a publicly revealed key and a secret key.  Each key unlocks the
  274.      code that the other key makes.  Knowing the public key does not help
  275.      you deduce the corresponding secret key.  The public key can be
  276.      published and widely disseminated across a communications network.
  277.      This protocol provides privacy without the need for the same kind of
  278.      secure channels that a conventional cryptosystem requires.
  279.       
  280.      Anyone can use a recipient's public key to encrypt a message to that
  281.      person, and that recipient uses her own corresponding secret key to
  282.      decrypt that message.  No one but the recipient can decrypt it,
  283.      because no one else has access to that secret key.  Not even the
  284.      person who encrypted the message can decrypt it.  
  285.       
  286.      Message authentication is also provided.  The sender's own secret key
  287.      can be used to encrypt a message, thereby "signing" it.  This creates
  288.      a digital signature of a message, which the recipient (or anyone
  289.      else) can check by using the sender's public key to decrypt it.  This
  290.      proves that the sender was the true originator of the message, and
  291.      that the message has not been subsequently altered by anyone else,
  292.      because the sender alone possesses the secret key that made that
  293.      signature.  Forgery of a signed message is infeasible, and the sender
  294.      cannot later disavow his signature. 
  295.       
  296.      These two processes can be combined to provide both privacy and
  297.      authentication by first signing a message with your own secret key,
  298.      then encrypting the signed message with the recipient's public key. 
  299.      The recipient reverses these steps by first decrypting the message
  300.      with her own secret key, then checking the enclosed signature with
  301.      your public key.  These steps are done automatically by the
  302.  
  303.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 7
  304.  
  305.  
  306.      recipient's software.
  307.       
  308.      Because the public key encryption algorithm is much slower than
  309.      conventional single-key encryption, encryption is better accomplished
  310.      by using a high-quality fast conventional single-key encryption
  311.      algorithm to encipher the message.  This original unenciphered
  312.      message is called "plaintext".  In a process invisible to the user, a
  313.      temporary random key, created just for this one "session", is used to
  314.      conventionally encipher the plaintext file.  Then the recipient's
  315.      public key is used to encipher this temporary random conventional
  316.      key.  This public-key-enciphered conventional "session" key is sent
  317.      along with the enciphered text (called "ciphertext") to the
  318.      recipient.  The recipient uses her own secret key to recover this
  319.      temporary session key, and then uses that key to run the fast
  320.      conventional single-key algorithm to decipher the large ciphertext 
  321.      message.
  322.       
  323.      Public keys are kept in individual "key certificates" that include
  324.      the key owner's user ID (which is that person's name), a timestamp of
  325.      when the key pair was generated, and the actual key material.  Public
  326.      key certificates contain the public key material, while secret key
  327.      certificates contain the secret key material.  Each secret key is
  328.      also encrypted with its own password, in case it gets stolen.  A key
  329.      file, or "key ring" contains one or more of these key certificates. 
  330.      Public key rings contain public key certificates, and secret key
  331.      rings contain secret key certificates.  
  332.       
  333.      The keys are also internally referenced by a "key ID", which is an 
  334.      "abbreviation" of the public key (the least significant 64 bits of 
  335.      the large public key).  When this key ID is displayed, only the lower
  336.      24 bits are shown for further brevity.  While many keys may share the
  337.      same user ID, for all practical purposes no two keys share the same
  338.      key ID.  
  339.       
  340.      PGP uses "message digests" to form signatures.  A message digest is a
  341.      128-bit cryptographically strong one-way hash function of the
  342.      message.  It is somewhat analogous to a "checksum" or CRC error
  343.      checking code, in that it compactly "represents" the message and is
  344.      used to detect changes in the message.  Unlike a CRC, however, it is
  345.      computationally infeasible for an attacker to devise a substitute
  346.      message that would produce an identical message digest.  The message
  347.      digest gets encrypted by the secret key to form a signature.  
  348.       
  349.      Documents are signed by prefixing them with signature certificates,
  350.      which contain the key ID of the key that was used to sign it, a
  351.      secret-key-signed message digest of the document, and a timestamp of
  352.      when the signature was made.  The key ID is used by the receiver to
  353.      look up the sender's public key to check the signature.  The
  354.      receiver's software automatically looks up the sender's public key
  355.      and user ID in the receiver's public key ring.
  356.       
  357.      Encrypted files are prefixed by the key ID of the public key used to
  358.      encrypt them.  The receiver uses this key ID message prefix to look
  359.      up the secret key needed to decrypt the message.  The receiver's 
  360.      software automatically looks up the necessary secret decryption key 
  361.      in the receiver's secret key ring.
  362.  
  363.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 8
  364.  
  365.  
  366.       
  367.      These two types of key rings are the principal method of storing and
  368.      managing public and secret keys.  Rather than keep individual keys in
  369.      separate key files, they are collected in key rings to facilitate the
  370.      automatic lookup of keys either by key ID or by user ID.  Each user
  371.      keeps his own pair of key rings.  An individual public key is
  372.      temporarily kept in a separate file long enough to send to your
  373.      friend who will then add it to her key ring.
  374.       
  375.       
  376.       
  377.      Installing PGP
  378.      ==============
  379.       
  380.      The MSDOS PGP 2.3 release comes in a compressed archive file called
  381.      PGP23.ZIP (each new release will have a name in the form "PGPxy.ZIP"
  382.      for PGP version number x.y).  The archive can be decompressed with
  383.      the MSDOS shareware decompression utility PKUNZIP, or the Unix
  384.      utility "unzip".  The PGP release package contains a README.DOC file
  385.      that you should always read before installing PGP.  This README.DOC
  386.      file contains late-breaking news on what's new in this release of
  387.      PGP, as well as information on what's in all the other files included
  388.      in the release.
  389.       
  390.      If you already have PGP version 1.0 for MSDOS, you should probably
  391.      delete it, because no one else uses it anymore.  If you don't want to
  392.      delete it, rename the old executable file to pgp1.exe, to avoid name
  393.      conflicts with the new PGP.
  394.       
  395.      To install PGP on your MSDOS system, you just have to copy the
  396.      compressed archive PGPxx.ZIP file into a suitable directory on your
  397.      hard disk (like C:\PGP), and decompress it with PKUNZIP.  For best
  398.      results, you will also modify your AUTOEXEC.BAT file, as described
  399.      elsewhere in this manual, but you can do that later, after you've
  400.      played with PGP a bit and read more of this manual.  If you haven't
  401.      run PGP before, the first step after installation (and reading this
  402.      manual) is to run the PGP key generation command "pgp -kg".
  403.       
  404.      Installing on Unix and VAX/VMS is generally similar to installing on
  405.      MSDOS, but you may have to compile the source code first.  A Unix
  406.      makefile is provided with the source release for this purpose.  
  407.       
  408.      For further details on installation, see the separate PGP
  409.      Installation Guide, in the file SETUP.DOC included with this
  410.      release.  It fully describes how to set up the PGP directory and your
  411.      AUTOEXEC.BAT file and how to use PKUNZIP to install it.
  412.       
  413.       
  414.       
  415.      How to Use PGP
  416.      ==============
  417.       
  418.       
  419.      To See a Usage Summary
  420.      ----------------------
  421.       
  422.  
  423.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am              Page 9
  424.  
  425.  
  426.      To see a quick command usage summary for PGP, just type:
  427.       
  428.          pgp -h
  429.       
  430.       
  431.       
  432.      Encrypting a Message
  433.      --------------------
  434.       
  435.      To encrypt a plaintext file with the recipient's public key, type:
  436.       
  437.          pgp -e textfile her_userid
  438.       
  439.      This command produces a ciphertext file called textfile.pgp.  A
  440.      specific example is:
  441.       
  442.          pgp -e letter.txt Alice
  443.      or:
  444.          pgp -e letter.txt "Alice S"
  445.       
  446.      The first example searches your public key ring file "pubring.pgp"
  447.      for any public key certificates that contain the string "Alice"
  448.      anywhere in the user ID field.  The second example would find any
  449.      user IDs that contain "Alice S".  You can't use spaces in the string
  450.      on the command line unless you enclose the whole string in quotes. 
  451.      The search is not case-sensitive.  If it finds a matching public key,
  452.      it uses it to encrypt the plaintext file "letter.txt", producing a
  453.      ciphertext file called "letter.pgp". 
  454.       
  455.      PGP attempts to compress the plaintext before encrypting it, thereby
  456.      greatly enhancing resistance to cryptanalysis.  Thus the ciphertext
  457.      file will likely be smaller than the plaintext file.
  458.       
  459.      If you want to send this encrypted message through E-mail channels,
  460.      convert it into printable ASCII "radix-64" format by adding the -a
  461.      option, as described later.
  462.       
  463.       
  464.       
  465.      Encrypting a Message to Multiple Recipients
  466.      -------------------------------------------
  467.       
  468.      If you want to send the same message to more than one person, you may
  469.      specify encryption for several recipients, any of whom may decrypt the
  470.      same ciphertext file.  To specify multiple recipients, just add more
  471.      user IDs to the command line, like so:
  472.       
  473.          pgp -e letter.txt Alice Bob Carol
  474.       
  475.      This would create a ciphertext file called letter.pgp that could be
  476.      decrypted by Alice or Bob or Carol.  Any number of recipients may be
  477.      specified.
  478.       
  479.       
  480.       
  481.      Signing a Message
  482.  
  483.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 10
  484.  
  485.  
  486.      -----------------
  487.       
  488.      To sign a plaintext file with your secret key, type:
  489.       
  490.          pgp -s textfile [-u your_userid]
  491.       
  492.      Note that [brackets] denote an optional field, so don't actually type
  493.      real brackets.  
  494.       
  495.      This command produces a signed file called textfile.pgp.  A specific 
  496.      example is:
  497.       
  498.          pgp -s letter.txt -u Bob
  499.       
  500.      This searches your secret key ring file "secring.pgp" for any secret
  501.      key certificates that contain the string "Bob" anywhere in the user
  502.      ID field.  The search is not case-sensitive.  If it finds a matching
  503.      secret key, it uses it to sign the plaintext file "letter.txt",
  504.      producing a signature file called "letter.pgp". 
  505.       
  506.      If you leave off the user ID field, the first key on your secret
  507.      key ring is used as the default secret key for your signature.
  508.       
  509.       
  510.       
  511.      Signing and then Encrypting
  512.      ---------------------------
  513.       
  514.      To sign a plaintext file with your secret key, and then encrypt it 
  515.      with the recipient's public key:
  516.       
  517.          pgp -es textfile her_userid [-u your_userid]
  518.       
  519.      Note that [brackets] denote an optional field, so don't actually type
  520.      real brackets.  
  521.       
  522.      This example produces a nested ciphertext file called textfile.pgp.
  523.      Your secret key to create the signature is automatically looked up in
  524.      your secret key ring via your_userid.  Her public encryption key is
  525.      automatically looked up in your public key ring via her_userid.  If
  526.      you leave off her user ID field from the command line, you will be 
  527.      prompted for it.
  528.       
  529.      If you leave off your own user ID field, the first key on your secret
  530.      key ring is be used as the default secret key for your signature.
  531.       
  532.      Note that PGP attempts to compress the plaintext before encrypting
  533.      it.
  534.       
  535.      If you want to send this encrypted message through E-mail channels,
  536.      convert it into printable ASCII "radix-64" format by adding the -a
  537.      option, as described later.
  538.       
  539.      Multiple recipients may be specified by adding more user IDs to the
  540.      command line.
  541.       
  542.  
  543.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 11
  544.  
  545.  
  546.       
  547.       
  548.      Using Just Conventional Encryption
  549.      ----------------------------------
  550.       
  551.      Sometimes you just need to encrypt a file the old-fashioned way, with
  552.      conventional single-key cryptography.  This approach is useful for
  553.      protecting archive files that will be stored but will not be sent to
  554.      anyone else.  Since the same person that encrypted the file will also
  555.      decrypt the file, public key cryptography is not really necessary. 
  556.       
  557.      To encrypt a plaintext file with just conventional cryptography,
  558.      type:
  559.       
  560.          pgp -c textfile
  561.       
  562.      This example encrypts the plaintext file called textfile, producing a
  563.      ciphertext file called textfile.pgp, without using public key
  564.      cryptography, key rings, user IDs, or any of that stuff.  It prompts
  565.      you for a pass phrase to use as a conventional key to encipher the
  566.      file.  This pass phrase need not be (and, indeed, SHOULD not be) the
  567.      same pass phrase that you use to protect your own secret key.  Note
  568.      that PGP attempts to compress the plaintext before encrypting it.  
  569.       
  570.      PGP will not encrypt the same plaintext the same way twice, even if
  571.      you used the same pass phrase every time.
  572.       
  573.       
  574.       
  575.      Decrypting and Checking Signatures
  576.      ----------------------------------
  577.       
  578.      To decrypt an encrypted file, or to check the signature integrity of a
  579.      signed file:
  580.       
  581.          pgp ciphertextfile [-o plaintextfile]
  582.       
  583.      Note that [brackets] denote an optional field, so don't actually type
  584.      real brackets.  
  585.       
  586.      The ciphertext file name is assumed to have a default extension of
  587.      ".pgp".  The optional plaintext output file name specifies where to
  588.      put processed plaintext output.  If no name is specified, the
  589.      ciphertext filename is used, with no extension.  If a signature is
  590.      nested inside of an encrypted file, it is automatically decrypted and
  591.      the signature integrity is checked.  The full user ID of the signer
  592.      is displayed.
  593.       
  594.      Note that the "unwrapping" of the ciphertext file is completely 
  595.      automatic, regardless of whether the ciphertext file is just signed,
  596.      just encrypted, or both.  PGP uses the key ID prefix in the
  597.      ciphertext file to automatically find the appropriate secret
  598.      decryption key on your secret key ring.  If there is a nested
  599.      signature, PGP then uses the key ID prefix in the nested signature to
  600.      automatically find the appropriate public key on your public key ring
  601.      to check the signature.  If all the right keys are already present on
  602.  
  603.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 12
  604.  
  605.  
  606.      your key rings, no user intervention is required, except that you
  607.      will be prompted for your password for your secret key if necessary. 
  608.      If the ciphertext file was conventionally encrypted without public
  609.      key cryptography, PGP recognizes this and prompts you for the pass
  610.      phrase to conventionally decrypt it.
  611.       
  612.       
  613.  
  614.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 13
  615.  
  616.  
  617.       
  618.      Managing Keys
  619.      =============
  620.       
  621.      Since the time of Julius Caesar, key management has always been the
  622.      hardest part of cryptography.  One of the principal distinguishing
  623.      features of PGP is its sophisticated key management.  
  624.       
  625.       
  626.       
  627.      RSA Key Generation
  628.      ------------------
  629.       
  630.      To generate your own unique public/secret key pair of a specified
  631.      size, type:  
  632.       
  633.          pgp -kg
  634.       
  635.      PGP shows you a menu of recommended key sizes (casual grade,
  636.      commercial grade, or military grade) and prompts you for what size
  637.      key you want, up to around a thousand bits.  The bigger the key, the
  638.      more security you get, but you pay a price in speed.  
  639.       
  640.      It also asks for a user ID, which means your name.  It's a good idea
  641.      to use your full name as your user ID, because then there is less
  642.      risk of other people using the wrong public key to encrypt messages
  643.      to you.  Spaces and punctuation are allowed in the user ID.  It would
  644.      help if you put your E-mail address in <angle brackets> after your
  645.      name, like so:
  646.        
  647.          Robert M. Smith <rms@xyzcorp.com>
  648.       
  649.      If you don't have an E-mail address, use your phone number or some
  650.      other unique information that would help ensure that your user ID is
  651.      unique.
  652.       
  653.      PGP also asks for a "pass phrase" to protect your secret key in case
  654.      it falls into the wrong hands.  Nobody can use your secret key file
  655.      without this pass phrase.  The pass phrase is like a password, except
  656.      that it can be a whole phrase or sentence with many words, spaces,
  657.      punctuation, or anything else you want in it.  Don't lose this pass
  658.      phrase-- there's no way to recover it if you do lose it.  This pass
  659.      phrase will be needed later every time you use your secret key.  The
  660.      pass phrase is case-sensitive, and should not be too short or easy to
  661.      guess.  It is never displayed on the screen.  Don't leave it written
  662.      down anywhere where someone else can see it, and don't store it on
  663.      your computer.  If you don't want a pass phrase (You fool!), just
  664.      press return (or enter) at the pass phrase prompt.
  665.       
  666.      The public/secret key pair is derived from large truly random numbers
  667.      derived mainly from measuring the intervals between your keystrokes
  668.      with a fast timer.  The software will ask you to enter some random
  669.      text to help it accumulate some random bits for the keys.  When
  670.      asked, you should provide some keystrokes that are reasonably random
  671.      in their timing, and it wouldn't hurt to make the actual characters
  672.      that you type irregular in content as well.  Some of the randomness
  673.  
  674.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 14
  675.  
  676.  
  677.      is derived from the unpredictability of the content of what you
  678.      type.  So don't just type repeated sequences of characters.
  679.       
  680.      Note that RSA key generation is a lengthy process.  It may take a few
  681.      seconds for a small key on a fast processor, or quite a few minutes
  682.      for a large key on an old IBM PC/XT.
  683.       
  684.      The generated key pair will be placed on your public and secret key
  685.      rings.  You can later use the -kx command option to extract (copy)
  686.      your new public key from your public key ring and place it in a
  687.      separate public key file suitable for distribution to your friends. 
  688.      The public key file can be sent to your friends for inclusion in
  689.      their public key rings.  Naturally, you keep your secret key file to
  690.      yourself, and you should include it on your secret key ring.  Each
  691.      secret key on a key ring is individually protected with its own pass
  692.      phrase.  
  693.       
  694.      Never give your secret key to anyone else.  For the same reason, don't
  695.      make key pairs for your friends.  Everyone should make their own key
  696.      pair.  Always keep physical control of your secret key, and don't risk
  697.      exposing it by storing it on a remote timesharing computer.  Keep it
  698.      on your own personal computer.
  699.       
  700.       
  701.       
  702.      Adding a Key to Your Key Ring
  703.      -----------------------------
  704.       
  705.      To add a public or secret key file's contents to your public or
  706.      secret key ring (note that [brackets] denote an optional field):
  707.       
  708.          pgp -ka keyfile [keyring]
  709.       
  710.      The keyfile extension defaults to ".pgp".  The optional keyring file
  711.      name defaults to "pubring.pgp" or "secring.pgp", depending on whether
  712.      the keyfile contains a public or a secret key.  You may specify a
  713.      different key ring file name, with the extension defaulting to
  714.      ".pgp".
  715.       
  716.      If the key is already on your key ring, PGP will not add it again. 
  717.      All of the keys in the keyfile are added to the keyring, except for
  718.      duplicates.  If the key being added has attached signatures
  719.      certifying it, the signatures are added with the key.  If the key is
  720.      already on your key ring, PGP just merges in any new certifying
  721.      signatures for that key that you don't already have on your key ring.
  722.       
  723.       
  724.       
  725.      Removing a Key or User ID from Your Key Ring
  726.      --------------------------------------------
  727.       
  728.      To remove a key or a user ID from your public key ring:
  729.       
  730.          pgp -kr userid [keyring]
  731.       
  732.      This searches for the specified user ID in your key ring, and removes
  733.  
  734.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 15
  735.  
  736.  
  737.      it if it finds a match.  Remember that any fragment of the user ID
  738.      will suffice for a match.  The optional keyring file name is assumed
  739.      to be literally "pubring.pgp".  It can be omitted, or you can specify
  740.      "secring.pgp" if you want to remove a secret key.  You may specify a
  741.      different key ring file name.  The default key ring extension is
  742.      ".pgp".
  743.       
  744.      If more than one user ID exists for this key, you will be asked if
  745.      you want to remove only the user ID you specified, while leaving the
  746.      key and its other user IDs intact.  
  747.       
  748.       
  749.       
  750.      Extracting (copying) a Key from Your Key Ring
  751.      ---------------------------------------------
  752.       
  753.      To extract (copy) a key from your public or secret key ring:
  754.       
  755.          pgp -kx userid keyfile [keyring]
  756.       
  757.      This non-destructively copies the key specified by the user ID from
  758.      your public or secret key ring to the specified key file.  This is
  759.      particularly useful if you want to give a copy of your public key to
  760.      someone else.
  761.       
  762.      If the key has any certifying signatures attached to it on your key
  763.      ring, they are copied off along with the key.
  764.       
  765.      If you want the extracted key represented in printable ASCII
  766.      characters suitable for email purposes, use the -kxa options.
  767.       
  768.       
  769.       
  770.      Viewing the Contents of Your Key Ring
  771.      -------------------------------------
  772.       
  773.      To view the contents of your public key ring:
  774.       
  775.          pgp -kv[v] [userid] [keyring] 
  776.       
  777.      This lists any keys in the key ring that match the specified user ID
  778.      substring.  If you omit the user ID, all of the keys in the key ring
  779.      are listed.  The optional keyring file name is assumed to be
  780.      "pubring.pgp".  It can be omitted, or you can specify "secring.pgp"
  781.      if you want to list secret keys.  If you want to specify a different
  782.      key ring file name, you can.  The default key ring extension is
  783.      ".pgp".  
  784.       
  785.      To see all the certifying signatures attached to each key, use the
  786.      -kvv option:
  787.       
  788.          pgp -kvv [userid] [keyring] 
  789.       
  790.      If you want to specify a particular key ring file name, but want to
  791.      see all the keys in it, try this alternative approach:
  792.       
  793.  
  794.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 16
  795.  
  796.  
  797.          pgp keyfile
  798.       
  799.      With no command options specified, PGP lists all the keys in
  800.      keyfile.pgp, and also attempts to add them to your key ring if they
  801.      are not already on your key ring.
  802.       
  803.       
  804.       
  805.      How to Protect Public Keys from Tampering
  806.      -----------------------------------------
  807.       
  808.      In a public key cryptosystem, you don't have to protect public keys
  809.      from exposure.  In fact, it's better if they are widely disseminated.
  810.      But it is important to protect public keys from tampering, to make
  811.      sure that a public key really belongs to whom it appears to belong to.
  812.      This may be the most important vulnerability of a public-key
  813.      cryptosystem.  Let's first look at a potential disaster, then at how
  814.      to safely avoid it with PGP.
  815.       
  816.      Suppose you wanted to send a private message to Alice.  You download
  817.      Alice's public key certificate from an electronic bulletin board
  818.      system (BBS).  You encrypt your letter to Alice with this public key
  819.      and send it to her through the BBS's E-mail facility.
  820.       
  821.      Unfortunately, unbeknownst to you or Alice, another user named
  822.      Charlie has infiltrated the BBS and generated a public key of his own
  823.      with Alice's user ID attached to it.  He covertly substitutes his
  824.      bogus key in place of Alice's real public key.  You unwittingly use
  825.      this bogus key belonging to Charlie instead of Alice's public key. 
  826.      All looks normal because this bogus key has Alice's user ID.  Now
  827.      Charlie can decipher the message intended for Alice because he has
  828.      the matching secret key.  He may even re-encrypt the deciphered
  829.      message with Alice's real public key and send it on to her so that no
  830.      one suspects any wrongdoing.  Furthermore, he can even make
  831.      apparently good signatures from Alice with this secret key because
  832.      everyone will use the bogus public key to check Alice's signatures.
  833.       
  834.      The only way to prevent this disaster is to prevent anyone from
  835.      tampering with public keys.  If you got Alice's public key directly
  836.      from Alice, this is no problem.  But that may be difficult if Alice
  837.      is a thousand miles away, or is currently unreachable.  
  838.       
  839.      Perhaps you could get Alice's public key from a mutual trusted friend
  840.      David who knows he has a good copy of Alice's public key.  David
  841.      could sign Alice's public key, vouching for the integrity of Alice's
  842.      public key.  David would create this signature with his own secret
  843.      key. 
  844.       
  845.      This would create a signed public key certificate, and would show
  846.      that Alice's key had not been tampered with.  This requires you have a
  847.      known good copy of David's public key to check his signature.  Perhaps
  848.      David could provide Alice with a signed copy of your public key also.
  849.      David is thus serving as an "introducer" between you and Alice.  
  850.       
  851.      This signed public key certificate for Alice could be uploaded by
  852.      David or Alice to the BBS, and you could download it later.  You
  853.  
  854.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 17
  855.  
  856.  
  857.      could then check the signature via David's public key and thus be
  858.      assured that this is really Alice's public key.  No impostor can fool
  859.      you into accepting his own bogus key as Alice's because no one else
  860.      can forge signatures made by David.
  861.       
  862.      A widely trusted person could even specialize in providing this
  863.      service of "introducing" users to each other by providing signatures
  864.      for their public key certificates.  This trusted person could be
  865.      regarded as a "key server", or as a "Certifying Authority".  Any
  866.      public key certificates bearing the key server's signature could be
  867.      trusted as truly belonging to whom they appear to belong to.  All
  868.      users who wanted to participate would need a known good copy of just
  869.      the key server's public key, so that the key server's signatures
  870.      could be verified.  
  871.       
  872.      A trusted centralized key server or Certifying Authority is
  873.      especially appropriate for large impersonal centrally-controlled
  874.      corporate or government institutions.  Some institutional
  875.      environments use hierarchies of Certifying Authorities.
  876.       
  877.      For more decentralized grassroots "guerrilla style" environments,
  878.      allowing all users to act as a trusted introducers for their friends
  879.      would probably work better than a centralized key server.  PGP tends
  880.      to emphasize this organic decentralized non-institutional approach. 
  881.      It better reflects the natural way humans interact on a personal
  882.      social level, and allows people to better choose who they can trust
  883.      for key management.
  884.       
  885.      This whole business of protecting public keys from tampering is the
  886.      single most difficult problem in practical public key applications. 
  887.      It is the "Achilles heel" of public key cryptography, and a lot of
  888.      software complexity is tied up in solving this one problem.  
  889.       
  890.      You should use a public key only after you are sure that it is a good
  891.      public key that has not been tampered with, and actually belongs to
  892.      the person it claims to.  You can be sure of this if you got this
  893.      public key certificate directly from its owner, or if it bears the
  894.      signature of someone else that you trust, from whom you already have
  895.      a good public key.  Also, the user ID should have the full name of
  896.      the key's owner, not just her first name.
  897.       
  898.      No matter how tempted you are-- and you will be tempted-- never,
  899.      NEVER give in to expediency and trust a public key you downloaded
  900.      from a bulletin board, unless it is signed by someone you trust. 
  901.      That uncertified public key could have been tampered with by anyone,
  902.      maybe even by the system administrator of the bulletin board.
  903.       
  904.      If you are asked to sign someone else's public key certificate, make
  905.      certain that it really belongs to that person named in the user ID of
  906.      that public key certificate.  This is because your signature on her
  907.      public key certificate is a promise by you that this public key
  908.      really belongs to her.  Other people who trust you will accept her
  909.      public key because it bears your signature.  It may be ill-advised to
  910.      rely on hearsay-- don't sign her public key unless you have
  911.      independent firsthand knowledge that it really belongs to her. 
  912.      Preferably, you should sign it only if you got it directly from her. 
  913.  
  914.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 18
  915.  
  916.  
  917.       
  918.      In order to sign a public key, you must be far more certain of that
  919.      key's ownership than if you merely want to use that key to encrypt a
  920.      message.  To be convinced of a key's validity enough to use it,
  921.      certifying signatures from trusted introducers should suffice.  But
  922.      to sign a key yourself, you should require your own independent
  923.      firsthand knowledge of who owns that key.  Perhaps you could call the
  924.      key's owner on the phone and read the key file to her to get her to
  925.      confirm that the key you have really is her key-- and make sure you
  926.      really are talking to the right person.  See the section called
  927.      "Verifying a Public Key Over the Phone" in the Special Topics volume
  928.      for further details.
  929.       
  930.      Bear in mind that your signature on a public key certificate does not
  931.      vouch for the integrity of that person, but only vouches for the
  932.      integrity (the ownership) of that person's public key.  You aren't
  933.      risking your credibility by signing the public key of a sociopath, if
  934.      you were completely confident that the key really belonged to him. 
  935.      Other people would accept that key as belonging to him because you
  936.      signed it (assuming they trust you), but they wouldn't trust that
  937.      key's owner.  Trusting a key is not the same as trusting the key's
  938.      owner.
  939.       
  940.      Trust is not necessarily transferable; I have a friend who I trust
  941.      not to lie.  He's a gullible person who trusts the President not to
  942.      lie.  That doesn't mean I trust the President not to lie.  This is
  943.      just common sense.  If I trust Alice's signature on a key, and Alice
  944.      trusts Charlie's signature on a key, that does not imply that I have
  945.      to trust Charlie's signature on a key.  
  946.       
  947.      It would be a good idea to keep your own public key on hand with a
  948.      collection of certifying signatures attached from a variety of
  949.      "introducers", in the hopes that most people will trust at least one
  950.      of the introducers who vouch for your own public key's validity. 
  951.      You could post your key with its attached collection of certifying
  952.      signatures on various electronic bulletin boards.  If you sign
  953.      someone else's public key, return it to them with your signature so
  954.      that they can add it to their own collection of credentials for their
  955.      own public key.
  956.       
  957.      PGP keeps track of which keys on your public key ring are properly
  958.      certified with signatures from introducers that you trust.  All you
  959.      have to do is tell PGP which people you trust as introducers, and
  960.      certify their keys yourself with your own ultimately trusted key.
  961.      PGP can take it from there, automatically validating any other keys
  962.      that have been signed by your designated introducers.  And of course
  963.      you may directly sign more keys yourself.  More on this later.
  964.       
  965.      Make sure no one else can tamper with your own public key ring.
  966.      Checking a new signed public key certificate must ultimately depend
  967.      on the integrity of the trusted public keys that are already on your
  968.      own public key ring.  Maintain physical control of your public key
  969.      ring, preferably on your own personal computer rather than on a
  970.      remote timesharing system, just as you would do for your secret key. 
  971.      This is to protect it from tampering, not from disclosure.  Keep a
  972.      trusted backup copy of your public key ring and your secret key ring
  973.  
  974.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 19
  975.  
  976.  
  977.      on write-protected media.
  978.       
  979.      Since your own trusted public key is used as a final authority to
  980.      directly or indirectly certify all the other keys on your key ring,
  981.      it is the most important key to protect from tampering.  To detect
  982.      any tampering of your own ultimately-trusted public key, PGP can be
  983.      set up to automatically compare your public key against a backup copy
  984.      on write-protected media.  For details, see the description of the
  985.      "-kc" key ring check command in the Special Topics volume.
  986.       
  987.      PGP generally assumes you will maintain physical security over your
  988.      system and your key rings, as well as your copy of PGP itself.  If an
  989.      intruder can tamper with your disk, then in theory he can tamper with
  990.      PGP itself, rendering moot the safeguards PGP may have to detect
  991.      tampering with keys.
  992.       
  993.      One somewhat complicated way to protect your own whole public key ring
  994.      from tampering is to sign the whole ring with your own secret key. 
  995.      You could do this by making a detached signature certificate of the
  996.      public key ring, by signing the ring with the "-sb" options (see the
  997.      section called "Separating Signatures from Messages" in the PGP
  998.      User's Guide, Special Topics volume).  Unfortunately, you would still
  999.      have to keep a separate trusted copy of your own public key around to
  1000.      check the signature you made.  You couldn't rely on your own public
  1001.      key stored on your public key ring to check the signature you made
  1002.      for the whole ring, because that is part of what you're trying to
  1003.      check.  
  1004.       
  1005.       
  1006.       
  1007.      How Does PGP Keep Track of Which Keys are Valid?
  1008.      ------------------------------------------------
  1009.       
  1010.      Before you read this section, be sure to read the above section on 
  1011.      "How to Protect Public Keys from Tampering".
  1012.       
  1013.      PGP keeps track of which keys on your public key ring are properly
  1014.      certified with signatures from introducers that you trust.  All you
  1015.      have to do is tell PGP which people you trust as introducers, and
  1016.      certify their keys yourself with your own ultimately trusted key.
  1017.      PGP can take it from there, automatically validating any other keys
  1018.      that have been signed by your designated introducers.  And of course
  1019.      you may directly sign more keys yourself.
  1020.       
  1021.      There are two entirely separate criteria PGP uses to judge a public
  1022.      key's usefulness-- don't get them confused: 
  1023.       
  1024.        1)  Does the key actually belong to whom it appears to belong?  
  1025.            In other words, has it been certified with a trusted signature?
  1026.        2)  Does it belong to someone you can trust to certify other keys?
  1027.       
  1028.      PGP can calculate the answer to the first question.  To answer the
  1029.      second question, PGP must be explicitly told by you, the user.  When
  1030.      you supply the answer to question 2, PGP can then calculate the
  1031.      answer to question 1 for other keys signed by the introducer you
  1032.      designated as trusted.
  1033.  
  1034.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 20
  1035.  
  1036.  
  1037.       
  1038.      Keys that have been certified by a trusted introducer are deemed
  1039.      valid by PGP.  The keys belonging to trusted introducers must
  1040.      themselves be certified either by you or by other trusted
  1041.      introducers.
  1042.       
  1043.      PGP also allows for the possibility of you having several shades of
  1044.      trust for people to act as introducers.  Your trust for a key's owner
  1045.      to act as an introducer does not just reflect your estimation of
  1046.      their personal integrity-- it should also reflect how competent you
  1047.      think they are at understanding key management and using good
  1048.      judgment in signing keys.  You can designate a person to PGP as
  1049.      unknown, untrusted, marginally trusted, or completely trusted to
  1050.      certify other public keys.  This trust information is stored on your
  1051.      key ring with their key, but when you tell PGP to copy a key off your
  1052.      key ring, PGP will not copy the trust information along with the key,
  1053.      because your private opinions on trust are regarded as confidential. 
  1054.       
  1055.      When PGP is calculating the validity of a public key, it examines the
  1056.      trust level of all the attached certifying signatures.  It computes a
  1057.      weighted score of validity-- two marginally trusted signatures are
  1058.      deemed as credible as one fully trusted signature.  PGP's skepticism
  1059.      is adjustable-- for example, you may tune PGP to require two fully
  1060.      trusted signatures or three marginally trusted signatures to judge a
  1061.      key as valid.
  1062.       
  1063.      Your own key is "axiomatically" valid to PGP, needing no introducer's
  1064.      signature to prove its validity.  PGP knows which public keys are
  1065.      yours, by looking for the corresponding secret keys on the secret
  1066.      key ring.  PGP also assumes you ultimately trust yourself to certify
  1067.      other keys.
  1068.       
  1069.      As time goes on, you will accumulate keys from other people that you
  1070.      may want to designate as trusted introducers.  Everyone else will
  1071.      each choose their own trusted introducers.  And everyone will
  1072.      gradually accumulate and distribute with their key a collection of
  1073.      certifying signatures from other people, with the expectation that
  1074.      anyone receiving it will trust at least one or two of the signatures. 
  1075.      This will cause the emergence of a decentralized fault-tolerant web
  1076.      of confidence for all public keys.
  1077.       
  1078.      This unique grass-roots approach contrasts sharply with Government
  1079.      standard public key management schemes, such as Internet Privacy
  1080.      Enhanced Mail (PEM), which are based on centralized control and
  1081.      mandatory centralized trust.  The standard schemes rely on a
  1082.      hierarchy of Certifying Authorities who dictate who you must trust. 
  1083.      PGP's decentralized probabilistic method for determining public key
  1084.      legitimacy is the centerpiece of its key management architecture. 
  1085.      PGP lets you alone choose who you trust, putting you at the top of
  1086.      your own private certification pyramid.  PGP is for people who prefer
  1087.      to pack their own parachutes.
  1088.       
  1089.       
  1090.       
  1091.      How to Protect Secret Keys from Disclosure
  1092.      ------------------------------------------
  1093.  
  1094.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 21
  1095.  
  1096.  
  1097.       
  1098.      Protect your own secret key and your pass phrase carefully.  Really,
  1099.      really carefully.  If your secret key is ever compromised, you'd
  1100.      better get the word out quickly to all interested parties (good luck)
  1101.      before someone else uses it to make signatures in your name.  For
  1102.      example, they could use it to sign bogus public key certificates,
  1103.      which could create problems for many people, especially if your
  1104.      signature is widely trusted.  And of course, a compromise of your own
  1105.      secret key could expose all messages sent to you.
  1106.       
  1107.      To protect your secret key, you can start by always keeping physical
  1108.      control of your secret key.  Keeping it on your personal computer at
  1109.      home is OK, or keep it in your notebook computer that you can carry
  1110.      with you.  If you must use an office computer that you don't always
  1111.      have physical control of, then keep your public and secret key rings
  1112.      on a write-protected removable floppy disk, and don't leave it behind
  1113.      when you leave the office.  It wouldn't be a good idea to allow your
  1114.      secret key to reside on a remote timesharing computer, such as a
  1115.      remote dial-in Unix system.  Someone could eavesdrop on your modem
  1116.      line and capture your pass phrase, and then obtain your actual secret
  1117.      key from the remote system.  You should only use your secret key on a
  1118.      machine that you have physical control over.  
  1119.       
  1120.      Don't store your pass phrase anywhere on the computer that has your
  1121.      secret key file.  Storing both the secret key and the pass phrase on
  1122.      the same computer is as dangerous as keeping your PIN in the same
  1123.      wallet as your Automatic Teller Machine bank card.  You don't want
  1124.      somebody to get their hands on your disk containing both the pass
  1125.      phrase and the secret key file.  It would be most secure if you just
  1126.      memorize your pass phrase and don't store it anywhere but your brain.  
  1127.      If you feel you must write down your pass phrase, keep it well
  1128.      protected, perhaps even more well protected than the secret key file.
  1129.       
  1130.      And keep backup copies of your secret key ring-- remember, you have
  1131.      the only copy of your secret key, and losing it will render useless
  1132.      all the copies of your public key that you have spread throughout the
  1133.      world.  
  1134.       
  1135.      The decentralized non-institutional approach PGP uses to manage
  1136.      public keys has its benefits, but unfortunately this also means we
  1137.      can't rely on a single centralized list of which keys have been
  1138.      compromised.  This makes it a bit harder to contain the damage of a
  1139.      secret key compromise.  You just have to spread the word and hope
  1140.      everyone hears about it.
  1141.       
  1142.      If the worst case happens-- your secret key and pass phrase are both
  1143.      compromised (hopefully you will find this out somehow)-- you will
  1144.      have to issue a "key compromise" certificate.  This kind of
  1145.      certificate is used to warn other people to stop using your public
  1146.      key.  You can use PGP to create such a certificate by using the "-kd"
  1147.      command.  Then you must somehow send this compromise certificate to
  1148.      everyone else on the planet, or at least to all your friends and
  1149.      their friends, et cetera.  Their own PGP software will install this
  1150.      key compromise certificate on their public key rings and will
  1151.      automatically prevent them from accidentally using your public key
  1152.      ever again.  You can then generate a new secret/public key pair and
  1153.  
  1154.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 22
  1155.  
  1156.  
  1157.      publish the new public key.  You could send out one package containing
  1158.      both your new public key and the key compromise certificate for your 
  1159.      old key.
  1160.       
  1161.       
  1162.       
  1163.      Revoking a Public Key
  1164.      ---------------------
  1165.       
  1166.      Suppose your secret key and your pass phrase are somehow both
  1167.      compromised.  You have to get the word out to the rest of the world,
  1168.      so that they will all stop using your public key.  To do this, you 
  1169.      will have to issue a "key compromise", or "key revocation" certificate
  1170.      to revoke your public key.
  1171.       
  1172.      To generate a certificate to revoke your own key, use the -kd
  1173.      command:
  1174.       
  1175.           pgp -kd your_userid
  1176.       
  1177.      This certificate bears your signature, made with the same key you are
  1178.      revoking.  You should widely disseminate this key revocation
  1179.      certificate as soon as possible.  Other people who receive it can add
  1180.      it to their public key rings, and their PGP software then
  1181.      automatically prevents them from accidentally using your old public
  1182.      key ever again.  You can then generate a new secret/public key pair
  1183.      and publish the new public key.
  1184.       
  1185.      You may choose to revoke your key for some other reason than the
  1186.      compromise of a secret key.  If so, you may still use the same
  1187.      mechanism to revoke it.
  1188.       
  1189.       
  1190.       
  1191.      What If You Lose Your Secret Key?
  1192.      ---------------------------------
  1193.       
  1194.      Normally, if you want to revoke your own secret key, you can use the
  1195.      "-kd" command to issue a revocation certificate, signed with your own
  1196.      secret key (see "Revoking a Public Key").  
  1197.       
  1198.      But what can you do if you lose your secret key, or if your secret
  1199.      key is destroyed?  You can't revoke it yourself, because you must use
  1200.      your own secret key to revoke it, and you don't have it anymore.  A
  1201.      future version of PGP will offer a more secure means of revoking keys
  1202.      in these circumstances, allowing trusted introducers to certify that
  1203.      a public key has been revoked.  But for now, you will have to get the
  1204.      word out through whatever informal means you can, asking users to
  1205.      "disable" your public key on their own individual public key rings.
  1206.       
  1207.      Other users may disable your public key on their own public key rings
  1208.      by using the "-kd" command.  If a user ID is specified that does not
  1209.      correspond to a secret key on the secret key ring, the -kd command
  1210.      will look for that user ID on the public key ring, and mark that
  1211.      public key as disabled.  A disabled key may not be used to encrypt
  1212.      any messages, and may not be extracted from the key ring with the -kx
  1213.  
  1214.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 23
  1215.  
  1216.  
  1217.      command.  It can still be used to check signatures, but a warning is
  1218.      displayed.  And if the user tries to add the same key again to his
  1219.      key ring, it will not work because the disabled key is already on the
  1220.      key ring.  These combined features will help curtail the further
  1221.      spread of a disabled key.
  1222.       
  1223.      If the specified public key is already disabled, the -kd command will
  1224.      ask if you want the key reenabled.
  1225.       
  1226.       
  1227.  
  1228.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 24
  1229.  
  1230.  
  1231.       
  1232.      Advanced Topics
  1233.      ===============
  1234.       
  1235.      Most of the "Advanced Topics" are covered in the "PGP User's Guide,
  1236.      Volume II:  Special Topics".  But here are a few topics that bear
  1237.      mentioning here.
  1238.       
  1239.       
  1240.      Sending Ciphertext Through E-mail Channels: Radix-64 Format
  1241.      -----------------------------------------------------------
  1242.       
  1243.      Many electronic mail systems only allow messages made of ASCII text,
  1244.      not the 8-bit raw binary data that ciphertext is made of.  To get
  1245.      around this problem, PGP supports ASCII radix-64 format for
  1246.      ciphertext messages, similar to the Internet Privacy-Enhanced Mail
  1247.      (PEM) format.  This special format represents binary data by using
  1248.      only printable ASCII characters, so it is useful for transmitting
  1249.      binary encrypted data through 7-bit channels or for sending binary
  1250.      encrypted data as normal E-mail text.  This format acts as a form of
  1251.      "transport armor", protecting it against corruption as it travels
  1252.      through intersystem gateways on Internet.  It also appends a CRC to 
  1253.      detect transmission errors.
  1254.       
  1255.      Radix-64 format converts the plaintext by expanding groups of 3
  1256.      binary 8-bit bytes into 4 printable ASCII characters, so the file
  1257.      grows by about 33%.  But this expansion isn't so bad when you
  1258.      consider that the file probably was compressed more than that by PGP
  1259.      before it was encrypted.
  1260.       
  1261.      To produce a ciphertext file in ASCII radix-64 format, just add the
  1262.      "a" option when encrypting or signing a message, like so:
  1263.       
  1264.          pgp -esa message.txt her_userid
  1265.       
  1266.      This example produces a ciphertext file called "message.asc" that
  1267.      contains data in a PEM-like ASCII radix-64 format.  This file can be
  1268.      easily uploaded into a text editor through 7-bit channels for
  1269.      transmission as normal E-mail on Internet or any other E-mail
  1270.      network.
  1271.       
  1272.      Decrypting the radix-64 transport-armored message is no different than
  1273.      a normal decrypt.  For example:
  1274.       
  1275.          pgp message
  1276.       
  1277.      PGP automatically looks for the ASCII file "message.asc" before it
  1278.      looks for the binary file "message.pgp".  It recognizes that the file
  1279.      is in radix-64 format and converts it back to binary before
  1280.      processing as it normally does, producing as a by-product a ".pgp"
  1281.      ciphertext file in binary form.  The final output file is in normal
  1282.      plaintext form, just as it was in the original file "message.txt".
  1283.       
  1284.      Most Internet E-mail facilities prohibit sending messages that are
  1285.      more than 50000 bytes long.  Longer messages must be broken into
  1286.      smaller chunks that can be mailed separately.  If your encrypted
  1287.  
  1288.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 25
  1289.  
  1290.  
  1291.      message is very large, and you requested radix-64 format, PGP 
  1292.      automatically breaks it up into chunks that are each small enough to
  1293.      send via E-mail.  The chunks are put into files named with extensions
  1294.      ".as1", ".as2", ".as3", etc.  The recipient must concatenate these
  1295.      separate files back together in their proper order into one big file
  1296.      before decrypting it.  While decrypting, PGP ignores any extraneous
  1297.      text in mail headers that are not enclosed in the radix-64 message
  1298.      blocks.
  1299.       
  1300.      If you want to send a public key to someone else in radix-64 format,
  1301.      just add the -a option while extracting the key from your keyring.
  1302.       
  1303.      If you forgot to use the -a option when you made a ciphertext file or
  1304.      extracted a key, you may still directly convert the binary file into
  1305.      radix-64 format by simply using the -a option alone, without any
  1306.      encryption specified.  PGP converts it to a ".asc" file.
  1307.       
  1308.      If you want to send through an E-mail channel a plaintext file that
  1309.      is signed but not encrypted, PGP will normally convert it all into
  1310.      radix-64 armor, rendering it unreadable to the casual human observer. 
  1311.      If the original plaintext message is in text (not binary) form, there
  1312.      is a way to send it through an E-mail channel in such a way that the
  1313.      ASCII armor is applied only to the binary signature certificate, but
  1314.      not to the plaintext message.  This makes it possible for the
  1315.      recipient to read the signed message with human eyes, without the aid
  1316.      of PGP.  Of course, PGP is still needed to actually check the
  1317.      signature.  For further information on this feature, see the
  1318.      explanation of the CLEARSIG parameter in the section "Setting
  1319.      Configuration Parameters: CONFIG.TXT" in the Special Topics volume.
  1320.       
  1321.       
  1322.      Environmental Variable for Path Name
  1323.      ------------------------------------
  1324.       
  1325.      PGP uses several special files for its purposes, such as your
  1326.      standard key ring files "pubring.pgp" and "secring.pgp", the random
  1327.      number seed file "randseed.bin", the PGP configuration file
  1328.      "config.txt", and the foreign language string translation file
  1329.      "language.txt".  These special files can be kept in any directory, by
  1330.      setting the environmental variable "PGPPATH" to the desired pathname. 
  1331.      For example, on MSDOS, the shell command:
  1332.       
  1333.          SET PGPPATH=C:\PGP
  1334.       
  1335.      makes PGP assume that your public key ring filename is 
  1336.      "C:\PGP\pubring.pgp".  Assuming, of course, that this directory
  1337.      exists.  Use your favorite text editor to modify your MSDOS
  1338.      AUTOEXEC.BAT file to automatically set up this variable whenever you
  1339.      start up your system.  If PGPPATH remains undefined, these special
  1340.      files are assumed to be in the current directory.
  1341.       
  1342.       
  1343.       
  1344.      Setting Configuration Parameters: CONFIG.TXT
  1345.      --------------------------------------------
  1346.       
  1347.  
  1348.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 26
  1349.  
  1350.  
  1351.      PGP has a number of user-settable parameters that can be defined in a
  1352.      special configuration text file called "config.txt", in the directory
  1353.      pointed to by the shell environmental variable PGPPATH.  Having a
  1354.      configuration file enables the user to define various flags and
  1355.      parameters for PGP without the burden of having to always define
  1356.      these parameters in the PGP command line.  
  1357.       
  1358.      With these configuration parameters, for example, you can control
  1359.      where PGP stores its temporary scratch files, or you can select what
  1360.      foreign language PGP will use to display its diagnostics messages and
  1361.      user prompts, or you can adjust PGP's level of skepticism in
  1362.      determining a key's validity based on the number of certifying
  1363.      signatures it has.
  1364.       
  1365.      For more details on setting these configuration parameters, see the
  1366.      appropriate section of the PGP User's Guide, Special Topics volume.
  1367.       
  1368.       
  1369.       
  1370.      Vulnerabilities
  1371.      ---------------
  1372.       
  1373.      No data security system is impenetrable.  PGP can be circumvented in
  1374.      a variety of ways.  Potential vulnerabilities you should be aware of
  1375.      include compromising your pass phrase or secret key, public key
  1376.      tampering, files that you deleted but are still somewhere on the
  1377.      disk, viruses and Trojan horses, breaches in your physical security,
  1378.      electromagnetic emissions, exposure on multi-user systems, traffic
  1379.      analysis, and perhaps even direct cryptanalysis.
  1380.       
  1381.      For a detailed discussion of these issues, see the "Vulnerabilities"
  1382.      section in the PGP User's Guide, Special Topics volume.
  1383.       
  1384.       
  1385.  
  1386.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 27
  1387.  
  1388.  
  1389.       
  1390.      Beware of Snake Oil
  1391.      ===================
  1392.       
  1393.      When examining a cryptographic software package, the question always
  1394.      remains, why should you trust this product?  Even if you examined the
  1395.      source code yourself, not everyone has the cryptographic experience
  1396.      to judge the security.  Even if you are an experienced cryptographer,
  1397.      subtle weaknesses in the algorithms could still elude you. 
  1398.       
  1399.      When I was in college in the early seventies, I devised what I
  1400.      believed was a brilliant encryption scheme.  A simple pseudorandom
  1401.      number stream was added to the plaintext stream to create
  1402.      ciphertext.  This would seemingly thwart any frequency analysis of
  1403.      the ciphertext, and would be uncrackable even to the most resourceful
  1404.      Government intelligence agencies.  I felt so smug about my
  1405.      achievement.  So cock-sure.  
  1406.       
  1407.      Years later, I discovered this same scheme in several introductory
  1408.      cryptography texts and tutorial papers.  How nice.  Other
  1409.      cryptographers had thought of the same scheme.  Unfortunately, the
  1410.      scheme was presented as a simple homework assignment on how to use
  1411.      elementary cryptanalytic techniques to trivially crack it.  So much
  1412.      for my brilliant scheme.
  1413.       
  1414.      From this humbling experience I learned how easy it is to fall into a
  1415.      false sense of security when devising an encryption algorithm.  Most
  1416.      people don't realize how fiendishly difficult it is to devise an
  1417.      encryption algorithm that can withstand a prolonged and determined
  1418.      attack by a resourceful opponent.  Many mainstream software engineers
  1419.      have developed equally naive encryption schemes (often even the very
  1420.      same encryption scheme), and some of them have been incorporated into
  1421.      commercial encryption software packages and sold for good money to
  1422.      thousands of unsuspecting users. 
  1423.       
  1424.      This is like selling automotive seat belts that look good and feel
  1425.      good, but snap open in even the slowest crash test.  Depending on
  1426.      them may be worse than not wearing seat belts at all.  No one
  1427.      suspects they are bad until a real crash.  Depending on weak
  1428.      cryptographic software may cause you to unknowingly place sensitive
  1429.      information at risk.  You might not otherwise have done so if you had
  1430.      no cryptographic software at all.  Perhaps you may never even
  1431.      discover your data has been compromised.
  1432.       
  1433.      Sometimes commercial packages use the Federal Data Encryption
  1434.      Standard (DES), a good conventional algorithm recommended by the
  1435.      Government for commercial use (but not for classified information,
  1436.      oddly enough-- hmmm).  There are several "modes of operation" the 
  1437.      DES can use, some of them better than others.  The Government
  1438.      specifically recommends not using the weakest simplest mode for
  1439.      messages, the Electronic Codebook (ECB) mode.  But they do recommend
  1440.      the stronger and more complex Cipher Feedback (CFB) or Cipher Block
  1441.      Chaining (CBC) modes.  
  1442.       
  1443.      Unfortunately, most of the commercial encryption packages I've looked
  1444.      at use ECB mode.  When I've talked to the authors of a number of
  1445.  
  1446.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 28
  1447.  
  1448.  
  1449.      these implementations, they say they've never heard of CBC or CFB
  1450.      modes, and didn't know anything about the weaknesses of ECB mode. 
  1451.      The very fact that they haven't even learned enough cryptography to
  1452.      know these elementary concepts is not reassuring.  These same
  1453.      software packages often include a second faster encryption algorithm
  1454.      that can be used instead of the slower DES.  The author of the
  1455.      package often thinks his proprietary faster algorithm is as secure as
  1456.      the DES, but after questioning him I usually discover that it's just
  1457.      a variation of my own brilliant scheme from college days.  Or maybe
  1458.      he won't even reveal how his proprietary encryption scheme works, but
  1459.      assures me it's a brilliant scheme and I should trust it.  I'm sure
  1460.      he believes that his algorithm is brilliant, but how can I know that
  1461.      without seeing it?  
  1462.       
  1463.      In all fairness I must point out that in most cases these products do
  1464.      not come from companies that specialize in cryptographic technology.
  1465.       
  1466.      There is a company called AccessData (87 East 600 South, Orem, Utah
  1467.      84058, phone 1-800-658-5199) that sells a package for $185 that
  1468.      cracks the built-in encryption schemes used by WordPerfect, Lotus
  1469.      1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0.  It
  1470.      doesn't simply guess passwords-- it does real cryptanalysis.  Some
  1471.      people buy it when they forget their password for their own files. 
  1472.      Law enforcement agencies buy it too, so they can read files they
  1473.      seize.  I talked to Eric Thompson, the author, and he said his
  1474.      program only takes a split second to crack them, but he put in some
  1475.      delay loops to slow it down so it doesn't look so easy to the
  1476.      customer.  He also told me that the password encryption feature of
  1477.      PKZIP files can often be easily broken, and that his law enforcement
  1478.      customers already have that service regularly provided to them from
  1479.      another vendor. 
  1480.       
  1481.      In some ways, cryptography is like pharmaceuticals.  Its integrity
  1482.      may be absolutely crucial.  Bad penicillin looks the same as good
  1483.      penicillin.  You can tell if your spreadsheet software is wrong, but
  1484.      how do you tell if your cryptography package is weak?  The ciphertext
  1485.      produced by a weak encryption algorithm looks as good as ciphertext
  1486.      produced by a strong encryption algorithm.  There's a lot of snake
  1487.      oil out there.  A lot of quack cures.  Unlike the patent medicine
  1488.      hucksters of old, these software implementors usually don't even know
  1489.      their stuff is snake oil.  They may be good software engineers, but 
  1490.      they usually haven't even read any of the academic literature in
  1491.      cryptography.  But they think they can write good cryptographic
  1492.      software.  And why not?  After all, it seems intuitively easy to do
  1493.      so.  And their software seems to work okay.    
  1494.       
  1495.      Anyone who thinks they have devised an unbreakable encryption scheme
  1496.      either is an incredibly rare genius or is naive and inexperienced.
  1497.       
  1498.      I remember a conversation with Brian Snow, a highly placed senior
  1499.      cryptographer with the NSA.  He said he would never trust an
  1500.      encryption algorithm designed by someone who had not "earned their
  1501.      bones" by first spending a lot of time cracking codes.  That did make
  1502.      a lot of sense.  I observed that practically no one in the commercial
  1503.      world of cryptography qualified under this criterion.  "Yes", he said
  1504.      with a self assured smile, "And that makes our job at NSA so much
  1505.  
  1506.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 29
  1507.  
  1508.  
  1509.      easier."  A chilling thought.  I didn't qualify either.
  1510.       
  1511.      The Government has peddled snake oil too.  After World War II, the US
  1512.      sold German Enigma ciphering machines to third world governments.
  1513.      But they didn't tell them that the Allies cracked the Enigma code
  1514.      during the war, a fact that remained classified for many years.  Even
  1515.      today many Unix systems worldwide use the Enigma cipher for file
  1516.      encryption, in part because the Government has created legal
  1517.      obstacles against using better algorithms.  They even tried to
  1518.      prevent the initial publication of the RSA algorithm in 1977.  And
  1519.      they have squashed essentially all commercial efforts to develop
  1520.      effective secure telephones for the general public. 
  1521.       
  1522.      The principle job of the US Government's National Security Agency is
  1523.      to gather intelligence, principally by covertly tapping into people's
  1524.      private communications (see James Bamford's book, "The Puzzle
  1525.      Palace").  The NSA has amassed considerable skill and resources for
  1526.      cracking codes.  When people can't get good cryptography to protect
  1527.      themselves, it makes NSA's job much easier.  NSA also has the
  1528.      responsibility of approving and recommending encryption algorithms. 
  1529.      Some critics charge that this is a conflict of interest, like putting
  1530.      the fox in charge of guarding the hen house.  NSA has been pushing a
  1531.      conventional encryption algorithm that they designed, and they won't
  1532.      tell anybody how it works because that's classified.  They want
  1533.      others to trust it and use it.  But any cryptographer can tell you
  1534.      that a well-designed encryption algorithm does not have to be
  1535.      classified to remain secure.  Only the keys should need protection. 
  1536.      How does anyone else really know if NSA's classified algorithm is
  1537.      secure?  It's not that hard for NSA to design an encryption algorithm
  1538.      that only they can crack, if no one else can review the algorithm. 
  1539.      Are they deliberately selling snake oil? 
  1540.       
  1541.      I'm not as certain about the security of PGP as I once was about my
  1542.      brilliant encryption software from college.  If I were, that would be
  1543.      a bad sign.  But I'm pretty sure that PGP does not contain any
  1544.      glaring weaknesses.  The crypto algorithms were developed by people
  1545.      at high levels of civilian cryptographic academia, and have been
  1546.      individually subject to extensive peer review.  Source code is
  1547.      available to facilitate peer review of PGP and to help dispel the
  1548.      fears of some users.  It's reasonably well researched, and has been
  1549.      years in the making.  And I don't work for the NSA.  I hope it
  1550.      doesn't require too large a "leap of faith" to trust the security of
  1551.      PGP.
  1552.       
  1553.       
  1554.  
  1555.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 30
  1556.  
  1557.  
  1558.       
  1559.      PGP Quick Reference
  1560.      ===================
  1561.       
  1562.      Here's a quick summary of PGP commands.
  1563.       
  1564.       
  1565.      To encrypt a plaintext file with the recipient's public key:
  1566.           pgp -e textfile her_userid
  1567.       
  1568.      To sign a plaintext file with your secret key:
  1569.           pgp -s textfile [-u your_userid]
  1570.       
  1571.      To sign a plaintext file with your secret key, and then encrypt it 
  1572.      with the recipient's public key:
  1573.           pgp -es textfile her_userid [-u your_userid]
  1574.       
  1575.      To encrypt a plaintext file with just conventional cryptography, type:
  1576.           pgp -c textfile
  1577.       
  1578.      To decrypt an encrypted file, or to check the signature integrity of a
  1579.      signed file:
  1580.           pgp ciphertextfile [-o plaintextfile]
  1581.       
  1582.      To encrypt a message for any number of multiple recipients:
  1583.           pgp -e textfile userid1 userid2 userid3
  1584.       
  1585.      --- Key management commands:
  1586.       
  1587.      To generate your own unique public/secret key pair:
  1588.           pgp -kg
  1589.       
  1590.      To add a public or secret key file's contents to your public or
  1591.      secret key ring:
  1592.           pgp -ka keyfile [keyring]
  1593.       
  1594.      To extract (copy) a key from your public or secret key ring:
  1595.           pgp -kx userid keyfile [keyring]
  1596.      or:  pgp -kxa userid keyfile [keyring]
  1597.       
  1598.      To view the contents of your public key ring:
  1599.           pgp -kv[v] [userid] [keyring] 
  1600.       
  1601.      To view the "fingerprint" of a public key, to help verify it over 
  1602.      the telephone with its owner:
  1603.           pgp -kvc [userid] [keyring]
  1604.       
  1605.      To view the contents and check the certifying signatures of your 
  1606.      public key ring:
  1607.           pgp -kc [userid] [keyring] 
  1608.       
  1609.      To edit the userid or pass phrase for your secret key:
  1610.           pgp -ke userid [keyring]
  1611.       
  1612.      To edit the trust parameters for a public key:
  1613.           pgp -ke userid [keyring]
  1614.  
  1615.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 31
  1616.  
  1617.  
  1618.       
  1619.      To remove a key or just a userid from your public key ring:
  1620.           pgp -kr userid [keyring]
  1621.       
  1622.      To sign and certify someone else's public key on your public key ring:
  1623.           pgp -ks her_userid [-u your_userid] [keyring]
  1624.       
  1625.      To remove selected signatures from a userid on a keyring:
  1626.           pgp -krs userid [keyring]
  1627.       
  1628.      To permanently revoke your own key, issuing a key compromise 
  1629.      certificate:
  1630.           pgp -kd your_userid
  1631.       
  1632.      To disable or reenable a public key on your own public key ring:
  1633.           pgp -kd userid
  1634.       
  1635.      --- Esoteric commands:
  1636.       
  1637.      To decrypt a message and leave the signature on it intact:
  1638.           pgp -d ciphertextfile
  1639.       
  1640.      To create a signature certificate that is detached from the document:
  1641.           pgp -sb textfile [-u your_userid]
  1642.       
  1643.      To detach a signature certificate from a signed message:
  1644.           pgp -b ciphertextfile
  1645.       
  1646.      --- Command options that can be used in combination with other 
  1647.      command options (sometimes even spelling interesting words!):
  1648.       
  1649.      To produce a ciphertext file in ASCII radix-64 format, just add the
  1650.      -a option when encrypting or signing a message or extracting a key:
  1651.           pgp -sea textfile her_userid
  1652.      or:  pgp -kxa userid keyfile [keyring]
  1653.       
  1654.      To wipe out the plaintext file after producing the ciphertext file,
  1655.      just add the -w (wipe) option when encrypting or signing a message:
  1656.           pgp -sew message.txt her_userid
  1657.       
  1658.      To specify that a plaintext file contains ASCII text, not binary, and
  1659.      should be converted to recipient's local text line conventions, add
  1660.      the -t (text) option to other options:
  1661.           pgp -seat message.txt her_userid
  1662.       
  1663.      To view the decrypted plaintext output on your screen (like the
  1664.      Unix-style "more" command), without writing it to a file, use 
  1665.      the -m (more) option while decrypting:
  1666.           pgp -m ciphertextfile
  1667.       
  1668.      To specify that the recipient's decrypted plaintext will be shown
  1669.      ONLY on her screen and cannot be saved to disk, add the -m option:
  1670.           pgp -steam message.txt her_userid
  1671.       
  1672.      To recover the original plaintext filename while decrypting, add 
  1673.      the -p option:
  1674.  
  1675.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 32
  1676.  
  1677.  
  1678.           pgp -p ciphertextfile
  1679.       
  1680.      To use a Unix-style filter mode, reading from standard input and
  1681.      writing to standard output, add the -f option:
  1682.           pgp -feast her_userid <inputfile >outputfile
  1683.       
  1684.       
  1685.       
  1686.  
  1687.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 33
  1688.  
  1689.  
  1690.       
  1691.      Legal Issues
  1692.      ============
  1693.       
  1694.      For detailed information on PGP licensing, distribution, copyrights,
  1695.      patents, trademarks, liability limitations, and export controls, see
  1696.      the "Legal Issues" section in the "PGP User's Guide, Volume II: 
  1697.      Special Topics".
  1698.       
  1699.      PGP uses a public key algorithm claimed by U.S. patent #4,405,829. 
  1700.      The exclusive rights to this patent are held by a California company
  1701.      called Public Key Partners, and you may be infringing this patent if
  1702.      you use PGP in the USA.  This is explained in the Volume II manual.
  1703.       
  1704.      PGP is "guerrilla" freeware, and I don't mind if you distribute it
  1705.      widely.  Just don't ask me to send you a copy.  Instead, you can get
  1706.      it yourself from many BBS systems and a number of Internet FTP sites.  
  1707.       
  1708.       
  1709.       
  1710.      Acknowledgments
  1711.      ================
  1712.       
  1713.      I'd like to thank the following people for their contributions to the
  1714.      creation of Pretty Good Privacy.  Although I was the author of PGP
  1715.      version 1.0, major parts of later versions of PGP were implemented by
  1716.      an international collaborative effort involving a large number of
  1717.      contributors, under my design guidance.  
  1718.       
  1719.      Branko Lankester, Hal Finney and Peter Gutmann all contributed a huge
  1720.      amount of time in adding features for PGP 2.0, and ported it to Unix
  1721.      variants.  Hal and Branko made Herculean efforts in implementing my
  1722.      new key management protocols.  Branko has spent more time on it than
  1723.      any other contributor to PGP.
  1724.       
  1725.      Hugh Kennedy ported it to VAX/VMS, Lutz Frank ported it to the Atari
  1726.      ST, and Cor Bosman and Colin Plumb ported it to the Commodore Amiga.
  1727.       
  1728.      Translation of PGP into foreign languages was done by Jean-loup
  1729.      Gailly in France, Armando Ramos in Spain, Felipe Rodriquez Svensson
  1730.      and Branko Lankester in The Netherlands, Miguel Angel Gallardo in
  1731.      Spain, Hugh Kennedy and Lutz Frank in Germany, David Vincenzetti in
  1732.      Italy, Harry Bush and Maris Gabalins in Latvia, Zygimantas Cepaitis
  1733.      in Lithuania, Peter Suchkow and Andrew Chernov in Russia, and
  1734.      Alexander Smishlajev in Esperantujo.  Peter Gutmann offered to
  1735.      translate it into New Zealand English, but we finally decided PGP
  1736.      could get by with US English.
  1737.       
  1738.      Jean-loup Gailly, Mark Adler, and Richard B. Wales published the ZIP
  1739.      compression code, and granted permission for inclusion into PGP.  The
  1740.      MD5 routines were developed and placed in the public domain by Ron
  1741.      Rivest.  The IDEA(tm) cipher was developed by Xuejia Lai and James L.
  1742.      Massey at ETH in Zurich, and is used in PGP with permission from
  1743.      Ascom-Tech AG. 
  1744.       
  1745.      Charlie Merritt originally taught me how to do decent multiprecision 
  1746.  
  1747.      PGPDOC1.TXT             Tuesday, June 15, 1993 12:39 am             Page 34
  1748.  
  1749.  
  1750.      arithmetic for public key cryptography, and Jimmy Upton contributed a
  1751.      faster multiply/modulo algorithm.  Thad Smith implemented an even
  1752.      faster modmult algorithm.  Zhahai Stewart contributed a lot of useful
  1753.      ideas on PGP file formats and other stuff, including having more than
  1754.      one user ID for a key.  I heard the idea of introducers from Whit
  1755.      Diffie.  Kelly Goen did most of the work for the initial electronic
  1756.      publication of PGP 1.0.
  1757.       
  1758.      Various contributions of coding effort also came from Colin Plumb,
  1759.      Derek Atkins, and Castor Fu.  Other contributions of effort, coding
  1760.      or otherwise, have come from Hugh Miller, Eric Hughes, Tim May,
  1761.      Stephan Neuhaus, and too many others for me to remember right now. 
  1762.      Two Macintosh porting projects have been underway, headed by Zbigniew
  1763.      Fiedorwicz and Blair Weiss.
  1764.       
  1765.      Since the release of PGP 2.0, many other programmers have sent in
  1766.      patches and bug fixes and porting adjustments for other computers.
  1767.      There are too many to individually thank here.
  1768.       
  1769.      The development of PGP has turned into a remarkable social
  1770.      phenomenon, whose unique political appeal has inspired the collective
  1771.      efforts of an ever-growing number of volunteer programmers.  Remember
  1772.      that children's story called "Stone Soup"?  It is getting harder to
  1773.      peer through the thick soup to see the stone at the bottom of the pot
  1774.      that I dropped in to start it all off.
  1775.       
  1776.       
  1777.       
  1778.      About the Author
  1779.      ================
  1780.       
  1781.      Philip Zimmermann is a software engineer consultant with 19 years
  1782.      experience, specializing in embedded real-time systems, cryptography,
  1783.      authentication, and data communications.  Experience includes design
  1784.      and implementation of authentication systems for financial
  1785.      information networks, network data security, key management
  1786.      protocols, embedded real-time multitasking executives, operating
  1787.      systems, and local area networks.  
  1788.       
  1789.      Custom versions of cryptography and authentication products and 
  1790.      public key implementations such as the NIST DSS are available from
  1791.      Zimmermann, as well as custom product development services.  His
  1792.      consulting firm's address is: 
  1793.       
  1794.      Boulder Software Engineering
  1795.      3021 Eleventh Street
  1796.      Boulder, Colorado 80304  USA
  1797.      Phone 303-541-0140 (voice or FAX)  (10:00am - 7:00pm Mountain Time)
  1798.      Internet:  prz@acm.org
  1799.       
  1800.